@bojh how can the temperature value be accessed then?

An example sketch would be helpful to explain this.

No problem at all. I have added an example requesting the SoC temperature.
Idea: I just saw, that we can change the "Environmental Sensing Service" (0x181e) and the characteristics service to "Temperature" (0x2A6e) using sint16.

@bojh thanks for adding the example, I'm still not keen about making the user extend a class to gain access to this feature ...

@sandeepmistry as I can asume the requestTemperuture() method was design originally for the externel nrf8001 sub-device as a async construction. For to keep the interface for nrf5x micro controller with softdevice a sync method could be called as it is relaized at the moment. So if you are not keen to support the current API for the device objects (nrf8001 & nrf51822 classes) an application also can call directly the softdevice function like the implementation in the nrf51822 class.

void nRF51822::requestTemperature() {
#ifndef __RFduino__
  int32_t rawTemperature = 0;

  sd_temp_get(&rawTemperature);

  float temperature = rawTemperature / 4.0;

  if (this->_eventListener) {
    this->_eventListener->BLEDeviceTemperatureReceived(*this, temperature);
  }
#endif
}

The pro argument: The applicaton does not have to create a BLEPeripheral subclass and should than directly call the softdevice function it self. The con: No unified way to get the SoC temperature.
Any thought from your side?

@bojh yes, that sound reasonable.

Maybe we should remove all of the battery level and temperature code from the library internals since it's not actually used or exposed?

@sandeepmistry with an viewing angle of an multi platform BLE library (i.e. Areduino101 CurieBLE) you are right. SoC temperature from nRF5 would than be more a library idea for arduino nRF5 core.

What is the status of this? Is requestTemperature() usable now?